abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 16:44 | Nová verze

    Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.18. Díky 174 přispěvatelům.

    Ladislav Hagara | Komentářů: 2
    dnes 15:11 | IT novinky

    Miliardy korun na digitalizaci služeb státu nestačily. Stát do ní v letech 2020 až 2024 vložil víc než 50 miliard korun, ale původní cíl se nepodařilo splnit. Od loňského února měly být služby státu plně digitalizované a občané měli mít právo komunikovat se státem digitálně. Do tohoto data se povedlo plně digitalizovat 18 procent agendových služeb státu. Dnes to uvedl Nejvyšší kontrolní úřad (NKÚ) v souhrnné zprávě o stavu digitalizace v Česku. Zpráva vychází z výsledků víc než 50 kontrol, které NKÚ v posledních pěti letech v tomto oboru uskutečnil.

    Ladislav Hagara | Komentářů: 6
    dnes 13:55 | IT novinky

    Nadace Wikimedia, která je provozovatelem internetové encyklopedie Wikipedia, oznámila u příležitosti 25. výročí vzniku encyklopedie nové licenční dohody s firmami vyvíjejícími umělou inteligenci (AI). Mezi partnery encyklopedie tak nově patří Microsoft, Amazon a Meta Platforms, ale také start-up Perplexity a francouzská společnost Mistral AI. Wikimedia má podobnou dohodu od roku 2022 také se společností Google ze skupiny

    … více »
    Ladislav Hagara | Komentářů: 0
    dnes 02:22 | Nová verze

    D7VK byl vydán ve verzi 1.2. Jedná se o fork DXVK implementující překlad volání Direct3D 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.

    Ladislav Hagara | Komentářů: 0
    dnes 02:00 | Nová verze

    Byla vydána verze 12.0.0 knihovny libvirt (Wikipedie) zastřešující různé virtualizační technologie a vytvářející jednotné rozhraní pro správu virtuálních strojů. Současně byl ve verzi 12.0.0 vydán související modul pro Python libvirt-python. Přehled novinek v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 0
    včera 19:22 | Humor

    CreepyLink.com je nový zkracovač URL adres, 'díky kterému budou vaše odkazy vypadat tak podezřele, jak je to jen možné'. Například odkaz na abclinuxu.cz tento zkracovač převádí do podoby 'https://netflix.web-safe.link/logger_8oIlgs_free_money.php'. Dle prohlášení autora je CreepyLink alternativou ke zkracovači ShadyURL (repozitář na githubu), který dnes již bohužel není v provozu.

    NUKE GAZA! 🎆 | Komentářů: 3
    včera 12:33 | IT novinky

    Na blogu Raspberry Pi byla představena rozšiřující deska Raspberry Pi AI HAT+ 2 s akcelerátorem Hailo-10 a 8 GB RAM. Na rozdíl od předchozí Raspberry Pi AI HAT+ podporuje generativní AI. Cena desky je 130 dolarů.

    Ladislav Hagara | Komentářů: 3
    včera 12:11 | Komunita

    Wikipedie slaví 25. výročí svého založení. Vznikla 15. ledna 2001 jako doplňkový projekt k dnes již neexistující encyklopedii Nupedia. Doména wikipedia.org byla zaregistrována 12. ledna 2001. Zítra proběhne v Praze Večer svobodné kultury, který pořádá spolek Wikimedia ČR.

    Ladislav Hagara | Komentářů: 1
    včera 04:44 | Nová verze

    Po více než dvou letech od vydání předchozí verze 2.12 byla vydána nová stabilní verze 2.14 systémového zavaděče GNU GRUB (GRand Unified Bootloader, Wikipedie). Přehled novinek v souboru NEWS a v aktualizované dokumentaci.

    Ladislav Hagara | Komentářů: 2
    včera 02:22 | Nová verze

    Google Chrome 144 byl prohlášen za stabilní. Nejnovější stabilní verze 144.0.7559.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 10 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře (YouTube).

    Ladislav Hagara | Komentářů: 4
    Které desktopové prostředí na Linuxu používáte?
     (14%)
     (5%)
     (0%)
     (9%)
     (19%)
     (3%)
     (6%)
     (3%)
     (11%)
     (43%)
    Celkem 461 hlasů
     Komentářů: 12, poslední 14.1. 21:12
    Rozcestník

    Jaderné noviny 261

    15. 6. 2004 | Robert Krátký | Jaderné noviny | 4019×

    LISP interpretr v kernelu. Obejití bufferové keše. Ovladač adm8211 802.11b pro 2.6. Skript pro patchování jádra - ketchup - ve verzi 0.5. Přidání podpory SysFS do DVB subsystému.

    Do konference přišlo celkem 999 emailů, nejvíce jich poslali Greg KH, Paul Jackson a Andrew Morton.

    LISP interpretr v kernelu, 84 e-mailů

    3. dub - 9. dub

    Tohle byla jedna z těch diskuzí typu "to by bylo zvláštní ale super", "ne to by tedy nebylo". Sergej Lozovsky ji začal docela nevinně, když se zeptal, jak řešit přetečení haldy v jádře. Pak se ukázalo, že jde o toto: Dal jsem do jádra LISP interpretr - http://vxe.quercitron.com - Funguje to, ale využívá hodně paměti haldy. Není to tak jednoduché přepsat, ale budu pátrat, proč to využívá tolik té paměti..

    Timothy Miller, který si v tomto vlákně nebral servítky, se dožadoval důvodu, který by ospravedlňoval přidávání interpretru Lispu do kernelu, a Sergej vysvětlil, že to bylo z bezpečnostních důvodů. Jednak to umožní systémovým administrátorům nakonfigurovat bezpečnostní pravidla systému bez překompilovávání jádra nebo psaní kódu v nízkoúrovňovém C; a zadruhé to ochrání systém před chybami v těchto bezpečnostních pravidlech, které se tam mohly dostat díky administrátorovi systému během konfigurace.

    Sergej pokračoval: LISP interpretr je LISP Virtual Machine (jako Java VM). Takže všechny chyby jsou uvnitř a neovlivní jádro. I vážné chyby v tomto modulu interpretru LISPu mohou způsobit pouze pád uživatelských aplikací (kromě toho přetečení haldy - o které mi jde). Chybová hláška LISPu bude zaznamenána v logu jádra.

    Následovala poměrně dlouhá diskuze, ve které lidi především předkládali jednu stížnost za druhou a Sergej se je všechny snažil vysvětlit. Jeden z argumentů byl, že celá ta věc patří do uživatelského prostoru a ne do kernelu. John Stoffel řekl, že by to celé muselo být přepracováno, aby byla alespoň malá naděje, že se to v jádře uchytí. Poukázal na všechny ochrany, které Sergej implementoval, aby zabránil chybám LISPu v ohrožení jádra, jako na důvod, proč ta věc patří do uživatelského prostoru. V uživatelském prostoru by těchto složitých ochran nebylo třeba. Sergej na to odpověděl tím, že se pouze snaží rozšířit tradiční unixový bezpečnostní model přirozenou cestou. Kdyby jeho interpretr LISPu patřil do uživatelského prostoru, pak by se dalo stejně argumentovat pro přesunutí kontroly oprávnění roota nebo přístupových práv k souborům do uživatelského prostoru.

    Další častou připomínkou byla prostě velikost té obludy. Timothy to vyjádřil v jednom ze svých příspěvků: LISP VM je velká, obrovská, nafouknutá... *CHRAPTÍM* *KAŠLU* *PRSKÁM* *DUSÍM SE* ... věc, která BY NIKDY NEMĚLA BÝT v jádře. Sergej reagoval, že velikost je pouhých 100K. Neimplementoval kompletní Common LISP interpretr, ale pouze malou část. Poznamenal, že se mu nepodařilo najít žádný virtuální stroj, který by se vešel do menšího prostoru. Robin Rosenberg připomněl LeJOS pro Lego Mindstorm, který se vejde do 32K a je licencován Mozilla licencí.

    Dalším námitky byly zaměřené na výběr jazyka LISP a že, jak se opět nechal slyšet Timothy, systémoví administrátoři by nikdy nepsali bezpečnostní pravidla v LISPu, ale spíše v něčem podobném unixovému shellu. Další možností by bylo vyvinout sadu nástrojů, které by kompilovaly pravidla napsaná v C do modulů dynamicky natahovaných do jádra :). Process kompilace by byl pro uživatele transparentní, protože nástroj "vložit toto pravidlo" by kompilaci prováděl pomocí GCC (pokud by v keši již nebyl aktuální .ko, atd.).

    Celkově poskytl Sergej zajímavé odpovědi na všechny námitky, ale nevypadalo to, že by někoho přesvědčil o tom důležitém, totiž jestli by taková věc měla v kernelu být.

    Obejití bufferové keše, 32 e-mailů

    6. dub - 10. dub

    Andy Isaacson napsal: Vypadá to, že v moderním Linuxu je správným způsobem, jak obejít bufferovou keš při zápisu na blokové zařízení, otevření blokového zařízení s O_DIRECT. To například uživateli umožňuje jednodušeji zajistit realokaci jediného sektoru na vadném IDE disku (bez přepisování čehokoliv jiného než toho 1k "sektorového páru" s chybou). dd(1) se pro tento účel hodí, ale postrádá způsob, který by zaručil použití O_DIRECT. Přiložený patch přidává parametr "conv=direct", který to umožňuje.

    Andrew Morton projevil velký zájem a požádal Andyho, aby provedl nějaké další pročišťující úpravy, když už v té oblasti pracuje. Andy však narazil na nějaké problémy a řekl: V 2.4.25 se mi vůbec nedaří O_DIRECT rozchodit na ext3 -- open(O_DIRECT) je úspěšné, ale zápis vrátí EINVAL.

    Andrew odpověděl: ext3 O_DIRECT v 2.4 jádrech nepodporuje. Kdysi jsem napsal patch a myslím, že je v 2.4-aa kernelech. ext3 podporuje O_DIRECT v jádrech 2.6. Dost dalších filesystémů rovněž.

    Posléze začalo být zřejmé, že Andy má v plánu implementovat podporu O_DIRECT pouze pro zápisy na disk, protože předpokládá, že pro čtení z disku k tomu není důvod. Ale Andrew prohlásil, že pro čtení i zápis existují stejné důvody, totiž že to šetří užití CPU a zabraňuje přílišnému používání bufferové keše. Andy souhlasil, že využití CPU by bylo s podporou O_DIRECT pro čtení nižší, ale ten zisk by byl tak mizivý, že to nestojí za implementaci.

    Pokračoval, že to považuje za práci jádra, aby přišlo na to, že "hele, vypadá to jako posloupné [streaming] čtení - ušetříme tedy bufferovou keš, protože se nebudeme pokoušet zachytit 20GB na systému s 512MB". Jestli chceš říct, že lidi kolem jádra to vzdali a řídí se teď pravidlem "pokud nechceš vyhodit všechno ostatní kvůli posloupným datům, musíš použít O_DIRECT", pak jsem tedy zklamaný. A uzavřel:

    Copak by otevření jak if=, tak of= s O_DIRECT neproměnilo dd v synchronní kopírku? To by bylo fakt na houby třeba v případě "dd if=/dev/hda1 of=/dev/hdc1". Když dělá bufferová keš readahead [načítání dopředu], zvládne ten příkaz nějakých 40MB/s čtení a 40MB/s psaní; se synchronním čtením i psaním by to kleslo na 40MB/s čtení+psaní, pokud by byly velikosti bloků dostatečné na to, aby se vyplatilo zpomalení kvůli hledání [seek overhead].

    Když je O_DIRECT pouze na of=, myslím, že se můžeme dostat zpět na 40MB/s+40MB/s.

    Tvrdím, že O_DIRECT na of= je důležité, protože vyškrábnout malé velikosti IDE bloků bez toho prostě nelze. Nevidím však žádnou podobnou výhodu použití O_DIRECT na straně if=.

    Andrewa nic z toho nepřesvědčilo a řekl naopak:

    Jestli chceš něco na vyškrábnutí bloků, napiš si to.

    Jestli chceš do dd přidat podporu O_DIRECT, pak by to mělo být implementováno správně, a to znamená implementováno jak pro zápis, tak pro čtení.

    Uživatel by měl vlastně mít možnost určit použití read-O_DIRECT a write-O_DIRECT nezávisle - třeba proto, že zdrojový a cílový filesystém nemusí oba O_DIRECT podporovat.

    Andy neměl pocit, že by to byl moc dobrý nápad, ale i tak napsal a poslal patch podle Andrewových požadavků. Někdy v tu dobu se ozval také Paul Eggert se svým patchem, který řešil ještě několik dalších věcí. Tento patch byl pak akceptován do 'coreutils'.

    Ovladač adm8211 802.11b pro 2.6, 1 e-mail

    10. dub

    Michael Wu napsal:

    Tady máte ovladač pro chipset adm8211 802.11b.

    http://aluminum.sourmilk.net/adm8211/adm8211-20040411.tar.bz2

    Je pouze pro jádra 2.6.x a ještě není tak docela hotov. Měl by fungovat v infrastrukturních a monitorovacích režimech, ale adhoc a WEP ještě nejdou. Běžná bezdrátová síť by měla fungovat dobře.

    Díky Jouni Malinenovi, že s tím ovladačem začal, Jerrittu Collordovi, že mi o tom řekl, a Davidu Youngovi za jeho NetBSD ovladač, který jsem použil jako referenci.

    Skript pro patchování jádra - ketchup - ve verzi 0.5, 2 e-maily

    11. dub

    Matt Mackall napsal: ketchup je skript, který automaticky patchuje mezi verzemi jádra, přičemž stahuje a ukládá patche podle potřeby. Automaticky také určuje poslední verze několika stromů. A pokračoval:

    Novinky v této verzi na žádost uživatelů:

    • změna jména kpatchup -> ketchup
    • automatické ověření podpisů
    • funguje se staršími verzemi Pythonu

    V současné době je výchozím chováním snaha použít gpg, což znamená, že musíte mít gpg nainstalované a příslušné klíče uložené ve vašem keyringu. Zbavit se toho můžete pomocí parametrů -g nebo --no-gpg.

    Najdete na:

    http://selenic.com/ketchup/ketchup-0.5

    Matt přiložil příklad použití ketchup:

     $ ketchup 2.6-mm
     2.6.3-rc1-mm1 -> 2.6.5-mm4
     Applying 2.6.3-rc1-mm1.bz2 -R
     Applying patch-2.6.3-rc1.bz2 -R
     Applying patch-2.6.3.bz2
     Applying patch-2.6.4.bz2
     Applying patch-2.6.5.bz2
     Downloading 2.6.5-mm4.bz2
     Downloading 2.6.5-mm4.bz2.sign
     Verifying signature...
     gpg: Signature made Sat Apr 10 21:55:36 2004 CDT using DSA key ID 517D0F0E
     gpg: Good signature from "Linux Kernel Archives Verification Key
     <ftpadmin@kernel.org>"
     gpg:                 aka "Linux Kernel Archives Verification Key
     <ftpadmin@kernel.org>"
     owner.
     gpg: WARNING: This key is not certified with a trusted signature!
     gpg:          There is no indication that the signature belongs to the
     Primary key fingerprint: C75D C40A 11D7 AF88 9981  ED5B C86B A06A 517D 0F0E
     Applying 2.6.5-mm4.bz2

    Přidání podpory SysFS do DVB subsystému, 3 e-maily

    12. dub

    V rámci pokračující snahy o zprovoznění všeho se SysFS pracoval Michael Hunold na přidání podpory SysFS do subsystému DVB. Nebyl si však jistý, jestli na to jde správně. Podařilo se mu vytvořit adresář /sys/class/dvb/, ale měl problémy s vytvářením podadresářů. Zeptal se proto na nějakou dokumentaci. Stephen Hemminger vysvětlil: Layout adresáře sysfs je logickou reprezentací příslušných datových struktur v jádře. Každý adresář (kromě skupin atributů) je 1:1 ke kobjectu. Greg KH dodal:

    Adresář nelze vytvořit pouhým přidáním '/' ke jménu třídy zařízení. Pro adresář bude třeba vytvořit kobject a v tomto kobjectu vytvořit atributy, jako v případě síťování.

    Jo, je to trochu otrava, ale vytváření podadresářů jednoduchým způsobem je na seznamu pro 2.7.

    Jestli chceš všechno urychlit, což by ti ušetřilo práci s přípravou pravidel životnosti tvých dvb ovladačů, můžeš implementovat rozhraní class_simple - stejně to teď dělá mnoho dalších ovladačových subsystémů. Ve 2.7 by se to pak převedlo na správný model konverze ovladačů.


    V originálu Kernel Traffic 261 vyšla navíc ještě tato témata:

    Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.
           

    Hodnocení: 42 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    15.6.2004 13:52 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
    Rozbalit Rozbalit vše LISP v jadre, tak tomu rikam jizda
    LISP v jadre tomu rikam sila neco do sebe to ma, ale pripada mi to mirne zvracene.

    btw. jeden operacni system s LISPem uz tu prece je GNU(/)Emacs :-))
    Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
    15.6.2004 15:05 fikus
    Rozbalit Rozbalit vše Re: LISP v jadre, tak tomu rikam jizda
    ja bych rekl, ze v jadre ma byt co nejmin veci. at zije mikrokernel :-)
    15.6.2004 20:01 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
    Rozbalit Rozbalit vše Re: LISP v jadre, tak tomu rikam jizda
    ovsem na to v linuxu muzeme zapomenout - at zije Hurd
    Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
    15.6.2004 22:06 penguin
    Rozbalit Rozbalit vše Re: LISP v jadre, tak tomu rikam jizda
    predem upozornuju, ze bych nerad rozpoutal flamewar, kdo ma mensi :o) kernel, ale kdyz uz se tu ta velikost zminuje, je nejaka "optimalni" nebo "bezna"? u vlastnorucne kompilovaneho jadra 2.4.22 je to 1,25 mb a u 2.6.6 1,5 mb. neni to moc? jak jste na tom vy?
    16.6.2004 02:32 kapo
    Rozbalit Rozbalit vše Re: LISP v jadre, tak tomu rikam jizda
    no ona ta velikost je uz zabalena. Zkus se podivat po kompilaci na soubor vmlinux, ja mam u 2.6.6 velikost cca 5MB (zkomprimovany to ma cca 2MB) :o) a to z tama mam vyhazeny firewire, LVM a vsecko mozny, co nepotrebuju.
    15.6.2004 16:18 Zdeněk Štěpánek | skóre: 57 | blog: uz_mam_taky_blog | varnsdorf
    Rozbalit Rozbalit vše hahahaha
    a nebylo by nejlepsi vsechno mozny i nemozny zkompilovat i s lilem do jedny 700MB velky binarky a vysmazit to na CD?

    lisp v kernelu povazuju za spatny vtip.

    zdenek
    www.pirati.cz - s piráty do parlamentu i jinam www.gavanet.org - czfree varnsdorf
    15.6.2004 18:57 David Jež | skóre: 42 | blog: -djz | Brno
    Rozbalit Rozbalit vše Re: hahahaha
    Klid, porad lepsi napad lisp v jadre nez java v jadre... Jinak doufam, ze takoveto mory v jadre nikdy nebudou :-).
    -djz
    "Yield to temptation; it may not pass your way again." -- R. A. Heinlein
    15.6.2004 20:08 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
    Rozbalit Rozbalit vše Re: hahahaha
    ja si myslim, ze kdyz je linux svobodny software, kazdy by mel mit neodpiratelne pravo sprasit si jadro dle sve libosti.

    kazdy si tam muze nas*t co se mu zlibi. treba pokud budu chtet mit syscall, ze se mne prepne obrazovka a bude zobrazovat obraz mao-ce-tunga. proc ne? porad to bude svobodny software at se vam to libi nebo ne.
    Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
    15.6.2004 20:48 Michal Čihař | skóre: 61 | blog: Bláboly | Praha
    Rozbalit Rozbalit vše Re: hahahaha
    Každý si může svoje jádro zprasit jak chce, ale ve zprasení vanilla kernelu musí fungovat nějaká omezení :-)
    15.6.2004 23:09 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
    Rozbalit Rozbalit vše Re: hahahaha
    tak to jo, RH a SUSE jadra v tomto pripade jednoznacne vedou na ty aplikovat dalsi patche je obcas porod
    Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.